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эксплуатации 
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Однопоточные* 
Данные и бизнес-логика рядом 
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про каждый кластер 


РВС-ргоху установлен 
локально к каждому 
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РВС-ргоху 
знает про шарды 


Занимает один 
хоп по сети 
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При отказе одного 

из серверов общее 
время ответа кластера 
увеличивается 
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Начинает 
страдать время 
ответа АР! 


Получаем отказ 
в обслуживании 
всего сайта 
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Побочным эффектом является то, 
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уводить трафик с загруженной 
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Результаты 


При нагрузке в 100% СРУ 
и утилизации канала сервер 
отбивал часть запросов, 
при этом не повышая 
задержку успешных 


При замедлении реплики 
часть запросов идет 

на соседнюю, снижая 
при этом нагрузку 

на загруженную 
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Некоторые 
трюки 
с мемкешом 


Метсасрпеа-5йт 


Порой ООМ-киллер или какая-то 
другая причина забирает лучших 


Для того чтобы не было так, был 
реализован простой аллокатор, 
использующий $Пагеда-тетогу 


МетсасГпеа- 
сит: аЙосатог 


Таблица з1хеба$5$-08: 


В нём тах 
512 чанков 


Визеагспй 
в момент аллокации 
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Метсаспеа-$Ит: статистика аллокаций 
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|6) |6) [6] |6) |6) 
1 6107 504133 |6) |6) 
2 82140 13986554 11698 11698 
З 1788281 94169784 483222 483222 
4 2849519 53064428 1551886 748672 
5 643132 24328205 871995 163772 
6 249453 23920864 284862 58490 
7 456909 12624350 340068 116980 
8 343046 28121403 567001 81886 
9 53230 4440532 56235 11698 
10 74278 4987243 20728 11698 
11 88363 11146533 43233 17663 
12 48847 10969569 35208 11698 
13 88861 11663046 36099 23384 
14 44527 7182312 12624 11698 
15 59629 17415728 12251 11698 
16 38810 6643563 21207 |6) 
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сое ВАА чер Для нас важна скорость и надежность 
огоху 
ответа мемкеша, поэтому мы стараемся 
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ходить всегда в локальный дата-центр, 
используя статистику времен ответа 
для этого 
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Проблема 


Часть кода собиралась старым 
компилятором, где несмотря 

на 11-ый стандарт, функция взятия 
размера выполнялась за линию 


Что не преминуло сказаться 
на графиках 


©. 


Проблема 


Часть кода собиралась старым 
компилятором, где несмотря 

на 11-ый стандарт, функция взятия 
размера выполнялась за линию 


Что не преминуло сказаться 
на графиках 


Решение 


Сейчас перешли на 20-ый стандарт 
и новые компиляторы, а для старых 
сборок где нужно подкладываем 
сборную солянку из старого ай6с 


Да, контейнеров у нас 
для движков нет 


ха, небольшая ивпрод 
задача на проксе 
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«Пакет смерти» 


Самолет не падает при отказе Баг Фикс бага 

одного двигателя ФФ Фр > 
) ‘Версия 

Так и здесь - при определенной ‘в проде 


конфигурации и определенной 
версии нашелся пакет, который 
вынес нам кеширующий слой 


и 


Экспериментальная 
выкатка КРС-ргоху 


«Пакет 
смерти»: 
решение 


Фазировали сеть 


Обновили везде 
критичные компоненты 


Сделали устойчивый 
к падениям кеширующий слой 


Хозяике 
на заметку 


Про 
р Не забывай про выравнивание 
компактность и сортировку типов в объекте 


Кеш скажет спасибо 
объекта 


А\/Х-инструкции часто 
могут дать выигрыш 
в несколько раз 


Агдоп2 крайне чувствителен 

к использованию векторных инструкций — 
использование А\Х-512Е ускоряет 

его работу в три раза по отношению 

к обычной реализации 


Переходы 
по указателям 


НЕ БЕСПЛАТНЫ 


Итерация в Б-дереве 
в 10х быстрее чем в $е 


Локальность обращений 
к памяти очень важна 


Заменили стандартный 
${4::5& на Б-дерево 


6-дерево вместо 
5фа::$ет 


Вся служебная информация 
в вершине Б-дерева занимает 8 байт 


‚ Размер поддерева 
вершины МАХ 2^31 [0:0, 3:0] 


. Капасити вершины [3:1, 4,6] 


. Фактический размер 
вершины [4:/, 6:2] 


. Бит листа [6:3] 


При факторе В=32 на один инстанс 
мы тратим 4,8 байт, а сет, например, 
40 байт 


Используем 
устройство указателей 
для тегирования 


Причем используем это двунаправленно, 
младшие три бита указателя 
из-за смещения также будут всегда нули 


Старшие шестнадцать 
для решения АВА-проблемы 


Использование 
ЦОР-Базес- 
протокола 

в ОС позволяет 
снизить задержку 
И СЭКОНОМИТЬ 

на СРУ/КАМ 


За счёт кастомной реализации 
КРС-протокола на базе ЦОР 
мы ушли от проблем: 


. реаа о! те Бюоскта 
. растущего хвоста |а1епсу 


. Лишнее потребляемых ресурсов 


Когда записи 
немного, стоит 
задуматься об КСИ 


Мы научились не копировать 
всю структуру данных и отказались 
от счетчиков ссылок для сущностей 


Но об этом в другом докладе :;) 


Вместо 
заключения 


Бенчмарк- Используйте фазеры Будьте аккуратны Ошибаются все, 
бенчмарк-бенчмарк, и ргорейу-ВБазед- с продакшном главное - правильно 
не доверяйте тестирование сделать выводы 
экспертам 


Спасибо 
за внимание! 


